1. Field of the Invention
The embodiments disclosed herein relate to the field of integrated circuits and, more particularly, to creating a secure software representation of a circuit design for use in testing and/or verification with a software-based simulator.
2. Description of the Related Art
Modern integrated circuits (ICs) are developed through the use of hardware description languages (HDLs). HDLs such as Verilog®, VHDL®, and the like allow developers to create software-based representations of circuit designs. One advantage of using an HDL is the potential for code reuse from one design to another. This concept has been realized with the commercial availability of intellectual property (IP) cores. In general, an IP core refers to a software representation of a semiconductor, a circuit design, or any portion thereof, that provides a processing function.
IP cores are made available by hardware vendors and other third party suppliers. Presently, there is a strong demand for IP cores as designers use these software components to create and simulate embedded designs and digital signal processing designs. IP cores typically are implemented in an HDL. If distributed in this form, however, all information, whether licensed or not, relating to the supplier's IP core or the circuit design represented by the IP core would be revealed to third parties. Accordingly, IP core providers have an interest in securing IP cores prior to distribution and protecting them from reverse engineering.
One technique for securing an IP core is to pre-compile it prior to distribution to third parties. The IP core is distributed as compiled object code, which effectively encrypts the IP core. This manner of protection requires that the IP core be compiled specifically for use with each different third party simulation tool with which the IP core is to be used. The IP core is compiled using a third party compiler intended for use with the target simulator. Because the IP core is originally coded in a particular type of HDL, such as Verilog® for example, the resulting compiled object code must be executed in a particular type of Simulator. For example, simulation of a Verilog® IP core requires a Verilog® simulator. Alternatively, the user can purchase a mixed language simulator capable of executing both Verilog® and VHDL® IP cores. Mixed language simulators, however, can be very costly for the end user.
Another disadvantage of providing a pre-compiled IP cores is that the IP core may not be completely secure. Because the IP core is compiled using a third party compiler, it may be possible for the compiler creator, or another party, to inadvertently or deliberately reconstitute the object code into human readable form. This would expose the IP core provider's sensitive information.
Even if the IP core is not de-compiled, many third party encryption mechanisms still leave design details, such as the design hierarchy, exposed when the compiled IP core is used within the simulator. For example, when the compiled code of the IP is loaded into an HDL simulator, details such as the design hierarchy, names of signals, widths of signals, and the like, typically can be viewed. Also, the values of internal signals can be traced and/or viewed during simulation.
Another technique for securing an IP core is to provide the IP core in encrypted form. In that case, the IP core provider provides an interface, for example a SWIFT model (a description can be found at www.synopsys.com/products/ipmodeling/vmc_ds.html), to the encrypted IP core. This manner of protection, however, is not suited for use with parameterizable IP cores. A parameterizable IP core allows a user to specify a particular value for an attribute “X” of the IP core, thereby altering the functionality and/or interface of the IP core in some fashion according to the assigned value of “X”. To produce a parameterizable, encrypted IP core, a different interface would have to be created for each possible value of “X” for the end user to utilize the full range of functionality offered by the parameterizable IP core. If the IP core has more than one adjustable attribute, such an interface would need to be created for each possible combination of attribute values, leading to a combinatorially large, and infeasible, number of interfaces to be created.
It would be beneficial to provide a technique for creating and using secure IP cores in a manner which overcomes the limitations described above.